This one isn't a big deal but when using esbuild to bundle a Cloudflare Worker, I usually add the workerd condition to my esbuild config to get my dependencies to use worker-compatible versions. However, when using @libsql/client/web, the build fails with error no such module 'node:http which is imported in the node export of isomorphic-fetch. To fix this, I add platform: browser to my config, forcing it to use the web export of isomorphic-fetch.

The build then fails with could not resolve module node:crypto (or any compatible node builtin as these don't exist in a browser environment. To fix this I have to externalise all node builtins I may be using so my esbuild config ends up being:

import esbuild from "esbuild";

esbuild.build({
	platform: "browser",
	external: ["node:crypto", "node:process", "node:async_hooks"],
	conditions: ["workerd"],
});

Dependencies may also be using node builtins internally so what I end up usually doing is:

import esbuild from "esbuild";
import { builtinModules } from "node:module";

esbuild.build({
	platform: "browser",
	external: [...builtinModules, ...builtinModules.map((m) => `node:${m}`)],
	conditions: ["workerd"],
});

This happens because of the ordering of the export in the package.json, where the node condition takes precedence over the workerd condition. This PR simply swaps the priority. Here's an excerpt from the Conditional Export docs:

Within the "exports" object, key order is significant. During condition matching, earlier entries have higher priority and take precedence over later entries. The general rule is that conditions should be from most specific to least specific in object order.

Not sure what side effects this change may cause so feel free to close it if it breaks something, would just be nice to not have to do this on every project using this with esbuild and have everything configurable with just conditions.